In a product company, changes are inevitable so as to best support the strategy and the vision. Often during such a change, new teams are formed and other ones are restructured. While there are many challenges to be solved during a big change, there’s one in particular that’s often overlooked: system ownership. Having experienced not-so-successful handovers, I was inspired to create a guideline that will help other teams do handovers differently.
This blog post explains how the Content Team at SoundCloud introduced a process for creating stretch opportunities for its engineers.
Although it can be easy to know if you’ve messed up badly as a manager, it’s not always as easy to know if you’re doing a good job. In particular, the power dynamics at play can make it hard for people on your team to feel confident letting you know what’s working well and what’s working not so well. In this article, I’m going to talk about an approach I started using in the last few years that seems to strike the best balance of getting the input managers need while still promoting a healthy culture of direct feedback.
One challenge engineering teams often face is dealing with work that doesn’t revolve around developing new features but that still requires the team’s attention and time. The Content Engineering Team here at SoundCloud is no exception, so we iterated on a process to deal with unplanned and support tasks to end up with fewer interruptions and more time to spend on implementing planned features.
Product development flow (flow) is the rate at which our products are developed, from idea to deployment. Good flow means that products should pass through the development cycle quickly and continuously.